1. Field of the Invention
The present invention relates generally to network node emulation, and more particularly to emulation of network node behavior.
2. Description of the Background Art
Computer networks have become widespread and ubiquitous. They are commonly used for data storage and manipulation, communications, commerce, information procurement, etc. By connecting together (networking) multiple computers or multiple computer networks, information may be easily shared, and shared in an almost instantaneous fashion.
FIG. 1 shows a typical distributed electronic network 115 connecting two or more nodes, such as node A and node B as shown. The distributed electronic network 115 may be, for example, the Internet. A network node is a computer or computer device that is connected to the network and communicates over the network 115. A computer network may contain many such nodes, including computers, workstations, servers, routers, gateways, switches, etc. A node therefore may be any device on the network 115 capable of transmitting and/or receiving data.
Data traveling on a computer network, such as over the Internet, for example, is typically in the form of a packet. Data in a data transmission is usually broken down into packets that are individually transmitted. A receiving device reassembles the data transmission when all of the packets have been received. The packets may pass through multiple networks and multiple network routers or gateways when traveling from one node to another.
FIG. 2 shows a packet 125 according to the TCP protocol. The packet 125 includes a source port 205 (i.e., a source address) and a destination port 210 (i.e., a destination address). By using the source and destination address, in conjunction with physical layer headers, a network device receiving the packet 125 may be able to determine whether to accept the packet, whether to pass the packet on to another device, or whether to ignore the packet. Additional information on packet structure and packet communication may be found in Douglas Corner, Internetworking with TCP/IP Volume 1 Principles, Protocols, and Architecture, 3rd Ed., Prentice-Hall, Englewood Cliffs, N.J., 1995, incorporated herein by reference.
One of the most significant challenges that exists in designing a new network node, a new network protocol, a new node software, etc., is in testing. Developers, manufacturers, distributors, users, etc., want to be sure that the product works properly and without causing problems for a target network and for nodes on the target network. Alternatively, an existing, functioning node may need to be tested to ensure proper operation or to ensure the ability to handle a desired level and type of data traffic.
The Internet, along with many other networks, employs the Transport Control Protocol/Internet Protocol (TCP/IP). TCP/IP dictates a standard software protocol and a standard transmission protocol, allowing interconnected networks to communicate. TCP/IP also dictates a standard reception protocol. TCP/IP based data networks are a unique grouping of network elements or nodes that adhere to the TCP/IP protocol in order to communicate. Such networks include many nodes, with the nodes being connected by an underlying network infrastructure. The network infrastructure may participate in basic communications between nodes.
In order to test software that operates the underlying network infrastructure, a test bed of network nodes may be employed, including real world nodes. These real world nodes must emulate day-to-day behavior in a controlled manner that allows a tester to accurately script reproducible behavior. The tester must also be able to script ad hoc behavior in order to stimulate nondeterministic (i.e., irregular or unpredictable) functionality.
The temporal characteristics of a network are rather difficult to capture due to their stochastic nature, but a functional breakdown shows that the most common compositional behavior is a regular transmission action and a pseudoregular reception action (pseudo because it is stimulated by a transmission from another node). The transmission action usually occurs with some periodicity, typically to output data. The reception action typically is a combination of a packet processing that results in some predetermined node application behavior and/or a packet processing that results in a protocol interaction behavior.
In the prior art, emulation or testing of node behavior has traditionally been done by directing manually formatted or pre-formatted packet traffic at a node. The data content is typically fixed. For example, the Internet Control Message Protocol (ICMP) may be used in troubleshooting network connectivity. It is accessible via simple network utilities like “ping” that periodically send out to a specified address. This is done manually by a user via a console.
Alternatively, using a traffic generation tool, a technician or operator may create or select test messages to be transmitted to a node under test. The drawbacks of this are the time and effort required, relatively large time gaps between messages, and the inability to fully emulate regular network traffic.
Immersing a node into an existing network is another way in which the node may be tested. An actual network environment may offer realistic message traffic loads, traffic types, and response times. However, it may not offer a tester the opportunity or ability to supplement the on-going message traffic and stretch the test environment beyond normal traffic levels and traffic types.
Real life testing may alternatively be done by creating a network test bed with multiple linked computers. However, this is expensive and time-consuming.
Testing has been performed through the use of specification languages that can be used in a computer device to create a test environment. Specification languages exist in the prior art for the purpose of describing and filtering packets. Some of the prior art specification languages are concerned with multiplexing/de-multiplexing and transmitting/receiving operations using a protocol stack. These operations are internal to the operation of the TCP/IP protocol and are not specific to host operations. The prior art specification languages allow fixed-time transmission and reception of packets because these languages are for synchronous programming of reactive systems. However, the specification languages of the prior art are more concerned with building type systems to represent packet structures with different degrees of refinement as part of a packet filter.
One example of a specification language is discussed in “Packet Types” by Satish Chandra and Peter J. McCann, Second Workshop on Compiler Support for Systems Software (WCSSS), May 1999, available on the world-wide web at “http://www.bell-labs.com/user/schandra/pubs.html”.
No device currently exists to fully emulate the behavior of a network node and to fully emulate the composition of network traffic. The prior art approaches are lacking in terms of automation, language specification, approximation of dynamic node behavior, and linkage to time scales. The prior art approaches are also lacking in an ability to individually address or characterize different aspects and attributes of the TCP/IP protocol. In addition, the prior art approaches do not have a central integration of TCP/IP functionality, are not independent of platform and operating systems, are not expandable to accommodate new protocols, and cannot specify data contents of generated transmit messages. The prior art includes no accommodation of data protocol specifications. More importantly, the approaches of the prior art are inadequate because they are merely reactive or filter-based. Fixed-time packet transmission and reception is inadequate to fully emulate interactive node behavior.
Therefore, the prior art tests only the bigger, more likely points of failure and emulates only simple node behaviors. Common test apparatus and procedures perform some tests of capacity, but only overall capacity and not capacity at the level of individual packets. In addition, the prior art approaches require specialized or additional hardware, and may not accommodate insertion of a node or node emulator into a real world network.
What is needed, therefore, is an improved instrumentality for network node emulation.